Island Architecture
概要
1. SSRなどによってサーバーでレンダリングされたHTMLの中にクライアント側(ブラウザー)において動的または対話的な振る舞いが必要な箇所(dynamic region※)に対してplaceholder(またはslot)を配置しておく ※ 概ね、このdynamic regionのことを"Island"と呼んでいるフレームワークが多そうです
2. クライアント(ブラウザー)では、サーバーでレンダリングされたHTMLに含まれる各placeholderを独立してhydrationする メリット
hydrationのタイミングを各dynamic region(Island)ごとに細かく制御できる
例えば、フレームワークによってはスクロールによってdynamic regionが可視範囲に入ったタイミングまでhydrationを遅延することも可能です (例: Astroにおけるclient:visibleディレクティブなど) 単一のコンポーネント(例えば<App>のようなコンポーネント)を一括でhydrateするのではなく、dynamic region(Island)ごとに個別にhydrateするため、個々のdynamic region(Island)におけるコードサイズは小さくなることが期待できる
相性が良さそうなユースケース
動的または対話的な振る舞いが必要な箇所のみをdynamic region(Island)として実装することで、ページ全体が占めるJavaScriptサイズの削減が期待できそうです いわゆる水平分割パターンによりMicro Frontendsを構築する場合、各チームが特定のdynamic region(Island)に責任を持つ、といった運用ができるかもしれません サポートしているフレームワーク
その他
リンク